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I REAL PARTY IN INTEREST (37 C.F.R. 41.37(c)(1)(i)) 

The real party in interest in this appeal is International Business Machines Corporation. 

II RELATED APPEALS AND INTERFERENCES (37 C.F.R. 41.37(c)(1)(ii)) 

There are no other appeals or interferences that will directly affect, or be directly affected by, or 
have a bearing on the Board's decision in the pending appeal. 

Ill STATUS OF CLAIMS (37 C.F.R. 41.37(c)(1)(iii)) 

A. TOTAL NUMBER OF CLAIMS IN APPLICATION 

Claims in the application are: 1-36 

B. STATUS OF ALL THE CLAIMS IN APPLICATION 

1. Claims pending: 1-36 

2. Claims canceled: none 

3. Claims withdrawn from consideration, but not canceled: none 

4. Claims allowed: none 

5. Claims rejected: 1-36 

C. CLAIMS ON APPEAL 

The claims on appeal are: 1-36 

IV STATUS OF AMENDMENTS (37 C.F.R. 41.37(c)(1)(iv)) 

AH amendments submitted by applicant have been entered. The Request for 
Reconsideration filed on February 17, 2004 was considered by the examiner as indicated in the 
office response dated May 4, 2004. 

V SUMMARY OF CLAIMED SUBJECT MATTER (37 C.F.R.41.37(c)(1)(v)) 

The present invention relates to an object-oriented system that uses distributed storage 
to store various objects on a set of computers connected by a network. In such a system, an 
object can be stored in a persistent repository 1320 by a server program on one computer, 
retrieved and manipulated by an application program 1300 in another computer and then stored 
again on the first computer. The invention is an object that is part of an application which 
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provides life cycle services, such as the creation, modification and destruction of objects. The 
inventive object is called a "moniker" object constructed from a moniker class 625 (Figure 6) and 
it assists an application program in storing and retrieving distributed objects so that the life cycle 
services system 1310, (Figure13), located in the memory 1308, can interact with the distributed 
objects and provide life cycle services (page 5, lines 17-25 and page 15, line 1 - page 16, line 
10). 

Normally, when an application program stores an object in local storage 1328, that 
object, including the object data and methods is streamed into the local storage 1328 where it 
can be maintained by the local life cycle services system 1310. However, in a distributed 
system, the application program may be using an object that is actually stored in a remote 
repository 1320, although the application 1300 may not be aware of this. From the application's 
point of view, it is performing a local storage operation and expects the local life cycle services 
system 1310 to manage the object. In order to allow the local life cycle services system 1310 to 
appear to manage the remote object, in accordance with the invention, a first stream object 
(TalonOutputStream Object, see page 10, line 27 - page 1 1 , line 8 ) is created from an output 
stream class 450 (Figure 4) to during the streaming of the object into local storage, a moniker 
object is automatically substituted for the actual distributed object (see Figures 13 and 14 and 
accompanying description at page 22, line 3 - page 23, line 3.) Thus, the moniker object is 
stored in local storage in place of the real object. The moniker object in the local storage can 
then be maintained by the inventive life cycle services system. The actual distributed object can 
be stored in the remote repository 1320. This happens transparently to the application program 
1300 which sees the object as being persisted in local storage 1328. 

Similarly, when an application program attempts to retrieve an object from local storage 
1528, the moniker object in local storage 1528 is instead streamed in from local storage 1528 by 
a second stream object (TalonlnputStream object instantiated from an InputStream class 440, 
page 1 1 , lines 3-8). During this streaming, a reference to the real distributed object is 
substituted for the moniker object in the local memory 1508. The real object is then created in 
the remote computer. (See Figures 15 and 16 and accompanying description at page 23, lines 
4-29). This transparent substitution allows the lifecycle services program 1310, which is located 
in the local computer to interact, with a local moniker object to provide the lifecycle services 
without modifying the application program to take into account the fact that the distributed object 
is not locally stored. 
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The moniker object of the present invention can also be used to locate the distributed 
object To this end, the inventive system maintains a runtime repository database 1 1 16 of 
moniker name-object reference pairs which it can use to look up a reference to the distributed 
object. If a moniker name is presented to this database and an object reference is not found, 
then the inventive system creates a directory service adapter object 1112 and uses it to query 
an existing directory service 1 1 14 in an attempt to locate the distributed object. (See Figures 1 1 
and 12 and the accompanying description at page 20, line 27 - page 22, line 2). 

VI GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL (37 C.F.R. 41.37(c)(1)(vi)) 

An examiner's interview was held on December 22, 2005 to clarify the status of the 
previous rejections of the claims as obvious under 35 U.S.C. §1 03(a) over U.S Patent No. 
6,263,379 (Atkinson) in view of U.S. Patent No. 6,460,058 (Koppolu). During that interview, 
applicant's attorney and the examiner agreed that the rejection under 35 U.S.C. §1 03(a) over 
Atkinson and Koppolu was withdrawn. If that rejection has not been withdrawn, arguments have 
been presented regarding the rejection in the Appeal Brief filed October 5, 2004 in this 
application which is hereby incorporated by reference. Therefore, claims 1-36 stand rejected 
only under 35 U.S.C. §1 03(a) as obvious over U.S Patent No. 6,263,379 (Atkinson) in view of 
U.S. Patent No. 5,212,790 (Ohler). 

VII ARGUMENT (37 C.F.R. 41.37(c)(1)(vii)) 

Prima facie obviousness has not been established because the combination of Atkinson 
and Ohler does not teach or suggest the structure recited in claims 1, 2, 5, 7, 9-12, 15, 17, 
19-22, 25, 27 and 29-30. 

Obviousness is a legal conclusion based on factual evidence. Graham v. John Deere 
Co. 383 US 1, 148 USPQ 459 (1966). The PTO has the burden under section 103 to establish 
a prima facie case of obviousness. In re Piasecki , 745 F.2d 1468, 1471-72, 223 USPQ 785, 
787-87 (Fed. Cir. 1984). To establish prima facie obviousness of a claimed invention, all the 
claim limitations must be taught or suggested by the prior art. In re Rovka , 490 F.2d 981, 180 
USPQ 580 (CCPA 1970.) 
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The Atkinson reference discloses "moniker" objects. However, although these objects 
have the same name as the moniker objects of the present invention, they have a different 
construction and function in an entirely different manner. Atkinson does not mention life cycle 
services and is not concerned with the problem solved by the present invention. The moniker 
objects disclosed in Atkinson are designed to assist a system that must work with diverse 
objects, each of which has its own interface. Atkinson discusses this problem in connection with 
application programs, such as word processing systems, that must operate on compound 
documents. These compound documents may contain linked or embedded data objects, such 
as spreadsheet objects, that have diverse interfaces. In the Atkinson system, a moniker object 
is used to provide a link to the data objects. Different moniker objects can be used to link to 
different types of objects, such as files, items and pointers. The advantage is that the moniker 
object has a consistent interface IMoniker. Thus, the application program can interact in a 
consistent way with the moniker object and the moniker object controls the real objects. 

In the Atkinson reference, the moniker object itself can be stored (persisted) and 
retrieved (resurrected.) In addition, the disclosed moniker objects (and the interface IMoniker) 
contain functions (BindToObject and BindToStorage) that allow the moniker object to store and 
retrieve the object to which the moniker object is bound. However, during the storage of the 
bound object, the moniker object is not substituted for the bound object so that the moniker 
object is stored in place of the bound object. For example, the moniker object can be used to 
store its bound object using the BindToStorage function. Then, the moniker object can itself be 
stored. This, results in both the moniker object and the bound object residing in local storage. If 
the moniker object was stored in place of the bound object, then only the moniker object would 
remain in storage after the store operation was complete. 

The Ohler patent discloses "phantom" objects that operate in a manner very similar to 
the moniker objects disclosed in Atkinson . In particular, a phantom object is created by a first 
process in the address space of that process. The first process locally accesses this phantom 
object and the phantom object then accesses a real object residing in the address space of 
another process. This operation is clearly disclosed in Ohler in the abstract and at column 2, 
lines 26-39, and allows a process to access an object in a local manner even though the object 
is actually a remote object. The Ohler patent does not mention any storage operation that 
stores either the phantom object or the real object. 
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The combination of Atkinson and Ohler does not teach or suggest the limitations recited 
in claims 1, 2, 5, 7, 9-12, 15, 17, 19-22, 25, 27 and 29-30. Claim 1 is representative of these 
claims and explicitly recites that the moniker object is substituted for the distributed object in the 
local storage during a storage operation so that the moniker object is stored in place of the 
distributed object. For example, claim 1, in lines 6-10, recites "a first stream object which 
automatically substitutes the moniker object for the distributed object during the streaming of the 
distributed object out from the memory to the local storage so that the moniker object is stored 
in the local storage in place of the distributed object." As set forth above, this operation does 
not occur in either of the cited references. Since neither reference shows this operation, the 
combination of the references cannot teach or suggest the operation. Consequently, claim 1 
patentably distinguishes over the cited references. 

The examiner acknowledges that Atkinson does not teach substituting the moniker 
object for the distributed object as recited in claim 1. However, the examiner claims that the 
Ohler reference at column 2, lines 8-40, discloses a phantom object being substituted for a 
distributed object during streaming of the distributed object. However, at column 2, lines 8-40, 
Ohler discloses a process that is substantially different from that recited in claim 1 . For 
example, Ohler states at column 2, lines 10-1 1 and lines 18-19, that the programmer creates 
the phantom object 14'd within process #1 before the process is executed. Claim 1, in lines 6-8, 
recites that a first stream object automatically substitutes the moniker object for the distributed 
object during the streaming of the distributed object out from the memory to the local storage. 
Similarly, Ohler states at column 2, lines 26-39, that when process #1 accesses phantom object 
a message is sent to the real object. The real object #4 14d then executes that message and 
returns the result to the phantom object, which, in turn, communicates the result to process #1. 
Ohler does not disclose what happens when either the phantom object or the real object is 
stored. Claim 1 recites, in lines 8-9, that the moniker object is stored in the local storage in 
place of the distributed object. 

Since Atkinson admittedly does not disclose the claimed subject matter and Ohler clearly 
does not disclose the claimed subject matter, the combination of Atkinson and Ohler explicitly 
pointed out by the examiner does not teach or suggest the limitations recited in claim 1 . Rather 
the combination teaches what both references teach: one object controlling another. 
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Prima facie obviousness has not been established because the combination of Atkinson 
and Ohler does not teach or suggest the structure recited in claims 3-4, 13-14 and 23-24. 

Claims 3-4, 13-14 and 23-24 are concerned with retrieving an object from local storage. 
Claim 3 is representative and recites "a second stream object which automatically substitutes a 
reference to the distributed object for the moniker object during the streaming of the moniker 
object in from the local storage to the memory so that a reference to the distributed object is 
created in memory in place of the moniker object.' 1 Thus, the second stream object retrieves a 
distributed object from "local" storage into memory by retrieving the moniker object from local 
storage, but then substituting a reference to the distributed object for the moniker object during 
the streaming of the moniker object into memory. This operation results in only the distributed 
object residing in memory. 

The examiner points to the IPersistStream disclosed in Atkinson at column 14, lines 37- 
65 as teaching a reference to the distributed object for the moniker object. First, it is noted that 
the IPersistStream is used in storing and retrieving the Atkinson moniker object itself. See 
Atkinson , column 14, lines 37-42. In order to use the Atkinson moniker object in a similar 
fashion to the claimed moniker object, the client would have to store the moniker object in local 
storage and then retrieve the moniker object and call the BindToObject method to instantiate the 
named object. This would certainly not be transparent as is the present invention. First, the 
client would have to be rewritten so that it stores and retrieves the moniker object instead of the 
named object. Then, after retrieving the moniker object, the client would have to explicitly call 
the BindToObject function. This results in both the moniker object and the bound object 
residing in memory. The distributed object is not "created in memory in place of the moniker 
object" as recited in claim 3. Further, the Atkinson process would not automatically substitute a 
reference to the distributed object for the moniker object during the streaming of the moniker 
object in from the local storage to the memory as recited in claim 3. Since the Ohler reference 
does not disclose storing or retrieving the phantom object, its combination with Atkinson does 
not alter or extend Atkinson's teachings. Thus, claim 3 patentably distinguishes over the cited 
combination of references. 

Prima facie obviousness has not been established because the combination of Atkinson 
and Ohler does not teach or suggest the structure recited in claims 6, 16 and 26. 
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Claims 6, 16 and 26 relate to a life cycle services object that manages the life cycle of 
the distributed object. Claim 6 is representative. The examiner claims that the 
CreateGenericComposite function disclosed in Atkinson , column 22, lines 37 et seq. discloses 
such a life cycle services object that can manage a distributed object in accordance with a life 
cycle services policy. However, the CreateGenericComposite function creates a composite 
moniker object from other moniker objects. While it might disclose creating a moniker object in 
accordance with a predefined policy, claim 6 recites that the life cycle services object manages 
the distributed object, not the moniker object. Ohler doesn't disclose anything about life cycle 
services. Therefore, its combination with Atkinson does not alter or extend Atkinson's 
teachings. Thus, claim 6 patentably distinguishes over the cited combination of references. 

Prima facie obviousness has not been established because the combination of Atkinson 
and Ohler does not teach or suggest the structure recited in claims 8, 18 and 28. 

Claims 8, 18 and 28 relate to location of a distributed object using an existing directory 
service. Claim 8 is representative. The examiner claims that Atkinson , at column 14, lines 34- 
47, teaches a directory service factory that responds to the moniker name by applying the 
moniker name to an existing directory service. However, at the recited column and lines, 
Atkinson actually states that each reference to a moniker object that is stored in, for example, a 
document contains a class ID and a reference to a named object. When a word processing 
program wants to display the document, it uses the class ID in the reference to access a 
moniker object factory to create the moniker object and then calls functions in the moniker 
object along with the reference to the named object to manipulate the named object. Directory 
services are not mentioned or needed since each reference to a moniker object will have a 
class Id for that object. Ohler does not disclose anything about directory services or directory 
service factories. Therefore, its combination with Atkinson does not alter or extend Atkinson's 
teachings. Thus, claim 8 patentably distinguishes over the cited combination of references. 

Prima facie obviousness has not been established because the combination of Atkinson 
and Ohler does not teach or suggest the structure recited in claims 31-36. 

Claims 31-36 recite that that the persistent repository in which the distributed object is 
stored is different from the local storage in which the moniker object is stored. Claim 31 is 
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representative. The examiner points to Ohler column 2, lines 15-17 as teaching the storage of 
the distributed object in a persistent repository different from local storage. However, at lines 
15-17, Ohler discloses that the phantom object is linked to the real object by process #2 and 
that the phantom object knows the location in memory of the real object. It is clear that the 
"memory" disclosed in Ohler corresponds to the "memory" recited in the claims because Ohler 
states that the objects are located within the "addressable memory" of the process (Ohler, 
column 1, lines 29-33). To one skilled in the art this would clearly mean that the "memory" to 
which Ohler refers is main memory. No local or remote storage is disclosed in Ohler . It is noted 
that the Ohler memory is neither persistent nor located remotely from the local storage as 
recited in the claims. Atkinson does not discuss a persistent repository or where this might be 
located. Therefore, its combination with Ohler does not alter or extend Ohler's teachings. 
Thus, claim 31 patentably distinguishes over the cited combination of references. 



Respectfully submitted 



Ufou/£ JhMstf Date: /^Uy/>^ 



Paul E. Kudirka, Esq. Reg. No. 26,931 
KUDIRKA & JOBSE, LLP 
Customer Number 021 127 
Tel: (617) 367-4600 Fax: (617) 367-4656 
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VIII APPENDIX OF CLAIMS (37 C.F.R. 41.37(c)(1)(viii)) 

The text of the claims involved in the appeal is: 



1 1 . Apparatus for use with a computer system having a memory, a local storage and an 

2 existing directory service operating in the memory, the apparatus providing naming and 

3 life cycle services for a distributed object and comprising: 

4 a moniker object which contains an identifier that universally identifies an 

5 instance of the distributed object and a moniker name; and 

6 a first stream object which automatically substitutes the moniker object for the 

7 distributed object during the streaming of the distributed object out from the memory to 

8 the local storage so that the moniker object is stored in the local storage in place of the 

9 distributed object. 

1 2. Apparatus according to claim 1 wherein the first stream object substitutes the moniker 

2 object for the distributed object when the distributed object is persisted. 

1 3. Apparatus according to claim 1 further comprising a second stream object which 

2 automatically substitutes a reference to the distributed object for the moniker object 

3 during the streaming of the moniker object in from the local storage to the memory so 

4 that a reference to the distributed object is created in memory in place of the moniker 

5 object. 

1 4. Apparatus according to claim 3 wherein the second stream object substitutes the 

2 moniker object for the distributed object when the distributed object is resurrected. 

in 



1 5. Apparatus according to claim 1 wherein life cycle services are provided by associating 

2 with the moniker object a predefined policy which specifies how and when life cycle 

3 services are performed. 

1 6. Apparatus according to claim 5 further comprising a life cycle services object which 

2 responds to the predefined policy by controlling the life cycle of the distributed object. 

1 7. Apparatus according to claim 1 further comprising a runtime repository which includes a 

2 database of moniker name-object reference pairs. 

1 8. Apparatus according to claim 7 further comprising a directory service factory object 

2 which responds to the moniker name by instantiating a directory service adapter object 

3 for applying the moniker name to the existing directory service when the runtime 

4 repository does not contain the moniker name. 

1 9. Apparatus according to claim 1 wherein the distributed object is instantiated in 

2 accordance with an object model and the apparatus comprises an object model adapter 

3 which processes distributed objects instantiated with the object model. 

1 1 0. Apparatus according to claim 9 wherein the object model adapter returns a reference to 

2 the distributed object together with a moniker object associated with the distributed 

3 object. 
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1 11. A method for use with a computer system having a memory, a local storage and an 

2 existing directory service operating in the memory, the method providing naming and life 

3 cycle services for a distributed object and comprising the steps of: 

4 (a) instantiating a moniker object which contains an identifier that universally 

5 identifies an instance of the distributed object and a moniker name; and 

6 (b) using a first stream object to automatically substitute the moniker object for the 

7 distributed object during the streaming of the distributed object out from the 

8 memory to the local storage so that the moniker object is stored in the local 

9 storage in place of the distributed object. 

1 12. A method according to claim 1 1 wherein step (b) comprises the step of: 

2 (b1 ) using the first stream object to substitute the moniker object for the distributed 

3 object when the distributed object is persisted. 

1 13. A method according to claim 1 1 further comprising the step of: 

2 (c) using a second stream object to automatically substitute a reference to the 

3 distributed object for the moniker object during the streaming of the moniker 

4 object in from the local storage to the memory so that a reference to the 

5 distributed object is created in memory in place of the moniker object. 

1 14. A method according to claim 13 wherein step (c) comprises the step of: 

2 (c1 ) using the second stream object to substitute the moniker object for the distributed 

3 object when the distributed object is resurrected. 
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1 15. A method according to claim 1 1 further comprising the step of: 

2 (d) associating with the moniker object a predefined policy which specifies how and 

3 when life cycle services are performed. 

1 16. A method according to claim 15 further comprising the step of: 

2 (e) instantiating a life cycle services object which responds to the predefined policy 

3 by controlling the life cycle of the distributed object. 

1 17. A method according to claim 1 1 further comprising the step of: 

2 (f) creating a runtime repository which includes a database of moniker name-object 

3 reference pairs. 

1 18. A method according to claim 17 further comprising the step of: 

2 (g) instantiating a directory service factory object which responds to the moniker 

3 name by instantiating a directory service adapter object for applying the moniker 

4 name to the existing directory service when the runtime repository does not 

5 contain the moniker name. 

1 19. A method according to claim 1 1 wherein the distributed object is instantiated in 

2 accordance with an object model and wherein the method comprises the step of: 

3 (h) instantiating an object model adapter which processes distributed objects 

4 instantiated with the object model. 
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1 20. A method according to claim 19 wherein step (h) comprises the step of: 

2 (hi ) returning a reference to the distributed object together with a moniker object 

3 associated with the distributed object. 

1 21 . A computer program product for use with a computer system having a memory, a local 

2 storage and an existing directory service operating in the memory, the computer 

3 program product providing naming and life cycle services for a distributed object and 

4 comprising a computer usable medium having computer readable program code thereon 

5 including: 

6 class code for instantiating a moniker object which contains an identifier that 

7 universally identifies an instance of the distributed object and a moniker name; and 

8 class code for instantiating a first stream object which automatically substitutes 

9 the moniker object for the distributed object during the streaming of the distributed object 

10 out from the memory to the local storage so that the moniker object is stored in the local 

1 1 storage in place of the distributed object. 

1 22. A computer program product according to claim 21 wherein the class code for 

2 instantiating a first stream object comprises method code for substituting the moniker 

3 object for the distributed object when the distributed object is persisted. 

1 23. A computer program product according to claim 21 further comprising class code for 

2 instantiating a second stream object which automatically substitutes a reference to the 

3 distributed object for the moniker object during the streaming of the moniker object in 
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4 from the local storage to the memory so that a reference to the distributed object is 

5 created in memory in place of the moniker object. 

1 24. A computer program product according to claim 23 wherein the class code for 

2 instantiating the second stream object includes method code for substituting the moniker 

3 object for the distributed object when the distributed object is resurrected. 

1 25. A computer program product according to claim 21 wherein the class code for 

2 instantiating the moniker object further comprises a method for associating with the 

3 moniker object a predefined policy which specifies how and when life cycle services are 

4 performed. 

1 26. A computer program product according to claim 25 further comprising class code for 

2 instantiating a life cycle services object which responds to the predefined policy by 

3 controlling the life cycle of the distributed object. 

1 27. A computer program product according to claim 21 further comprising program code for 

2 creating a runtime repository which includes a database of moniker name-object 

3 reference pairs. 

1 28. A computer program product according to claim 27 further comprising class code for 

2 instantiating a directory service factory object which responds to the moniker name by 

3 instantiating a directory service adapter object for applying the moniker name to the 



15 



4 



5 



existing directory service when the runtime repository does not contain the moniker 
name. 



1 29 A computer program product according to claim 21 wherein the distributed object is 

2 instantiated in accordance with an object model and wherein the computer program 

3 product comprises class code for instantiating an object model adapter which processes 

4 distributed objects instantiated with the object model. 

1 30. A computer program product according to claim 29 wherein an instantiated object model 

2 adapter comprises a method for returning a reference to the distributed object together 

3 with a moniker object associated with the distributed object. 

1 31 . Apparatus according to claim 1 wherein the first stream object comprises means 

2 operable during the streaming of the distributed object out from the memory to the local 

3 storage for storing the distributed object in a persistent repository that is different from 

4 the local storage. 

1 32. Apparatus according to claim 31 wherein the persistent repository is located remotely 

2 from the local storage. 

1 33 A method according to claim 1 1 further comprising: 

2 (c) using the first stream object during the streaming of the distributed object out 

3 from the memory to the local storage to store the distributed object in a persistent 

4 repository that is different from the local storage. 
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A method according to claim 33 wherein the persistent repository is located remotely 
from the local storage. 

A computer program product according to claim 21 wherein the first stream object 
comprises program code operable during the streaming of the distributed object out from 
the memory to the local storage for storing the distributed object in a persistent 
repository that is different from the local storage. 

A computer program product according to claim 35 wherein the persistent repository is 
located remotely from the local storage 
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